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

Post by iLemming » Sun, Jun 16, 2019, 11:12 AM UTC

massung wrote: post #132

galaxyLogic wrote: post #57

I think the big big result from this study is: "Python: half the size !". A dynamic language like Python is better here, 2x better. I assume similar results would apply to other dynamic languages like JavaScript, Lisp, Smalltalk, Groovy etc. This does not say that static typing should not be used but I think it shows unequivocally that there is a considerable extra development cost associated with static typing. You…

I enjoy hacking in dynamic languages as much as the next programmer. But, the big take-away is that "the initial implementation was done in 1/2 the code" not that the resulting code was more extensible or maintainable (by other programmers!). > You might say that surely that additional cost would be compensated in reducing the cost of maintenance later. Maybe but I'm not sure. I am sure. 100%. From many years of expe…

Post by grumdan » Sun, Jun 16, 2019, 11:27 AM UTC

fnord123 wrote: post #225

nybble41 wrote: post #149

Earlier quoted context omitted.

Right, to prove or disprove the norm one would need much more information. Two counterexamples does, however, disprove that "Parsing libraries ... just aren’t used for big projects." GHC and the OCaml compiler are both big projects, and they use parsing libraries.

I think big here means impactful.

Post by dean177 » Sun, Jun 16, 2019, 11:30 AM UTC

zimablue wrote: post #83

I feel like what you're actually testing with this is "amongst the top percentile of programmers, what are the proclivities of people by choice of favourite language" Because the implementations vary so much, that's the source of a lot of the LOC-difference. They effectively delivered more or less (if you count more stages as "more" which I would as it will make it easier to reason about/debug, and count a typesystem…

Post by foldr » Sun, Jun 16, 2019, 11:31 AM UTC

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…

Post by jcora » Sun, Jun 16, 2019, 11:35 AM UTC

ncmncm wrote: post #53

xyzzy_plugh wrote: post #44

Earlier quoted context omitted.

> Boost Spirit, a powerful parsing library I regularly use Boost Spirit as an example of "sounds good but actually a nightmare", and am always surprised to see it mentioned in the wild. It is truly a modern horror. Boost is like Apache -- a collection of libraries of various quality and stage of development, not all alike. A lot of stuff in there is designed to prove out experimental language features ahead of the ne…

You won't catch me arguing in favor of using Spirit. In general, it is rarely a good idea to rely on a library you don't understand. But Boost has serviceable variant, option, and result types.