My take-away from this article is that the university I graduated from was terrible
Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
201–210 of 384 posts
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#202Haskell 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 plus GC. Lets not pretend this is a fair comparison of languages when it's primarily a comparison of standard libraries.
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#203That is an important conclusion: "design decisions make a much larger difference than the language".
Software developers' expertise varies more than expressiveness of programming languages.
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#204Earlier quoted context omitted.
A typical translation of C++ code into D reduces the line count by a substantial amount, simply because D doesn't require .h files.
What are relative compile times like? Building Chromium atm, and to be honest I'd be happy if it were written in a trillion lines of BASIC if that would somehow achieve even a 10x build time speedup.
Think Delphi and .NET Native compile times.
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#205Earlier quoted context omitted.
What are relative compile times like? Building Chromium atm, and to be honest I'd be happy if it were written in a trillion lines of BASIC if that would somehow achieve even a 10x build time speedup.
For chromium, the most important concern will be runtime speed, more than compile time
Languages with native support for modules can have both.
Lets see how C++20 will improve the situation.
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#206Earlier quoted context omitted.
Sounds like he (edit: or more accurately, the university) has hasn't taught them enough functional programming and Haskell.
He teaches compilers. Not programming or fp, so definitely not the professors fault
Yes, but it's still a great pity, as Haskell, a descendent of ML (the "meta-language") is a suberb fit for writing a compiler.
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#207I really wish when counting code that people would use one of the more modern code counters, or at least use cloc. Tokei, loc, scc, polyglot, loccount or gocloc give a much better idea over wc because they account for comments and blank lines and in the case of scc and tokei strings. I had a similar experience in university. Class had to implement a modified Turing machine. We could use whatever language we wanted. O…
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.
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#208Where's the code? I scanned this article a few times and can't find a link to it.
None of it is open source because it was done for a school course that uses the same project every term. The only use for having access to the code would be cheating on that project. The school gets mad when people publish the source for their school projects, especially when it isn't otherwise useful, that's also why my ray tracer isn't open source.
Being a teacher myself, I understand this policy. Too bad, though, I'd have dearly loved to read the python implementation to rewrite it in Clojure. I think the language could allow for something at least as concise be maybe cleaner.
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#209I 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 also was surprised at the magnitude of the difference and am not sure the extra lines are worth it given the strong association between number of lines and number of defects.
Having said that, the largest point I took away was that the difference between languages was smaller than the difference between programmers and approaches.
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#210I 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…
When thinking about extending and refactoring, you also need to keep in mind that static types add a whole layer which is pretty hard to change. There are advantages and disadvantages, having at static types isn't such a silver bullet.