"Their project was 17,211 raw lines, 15k source lines, and 637kb" So a couple of students cranked out 15K lines of code, in basically a subset of their study time, for a single class? I don't doubt they did it, what I doubt is the quality of what they wrote. Because it's 'just a project' it doesn't have to be fully debugged ... But that is a vast amount of code to hand-write over a short period of time. At that level…
Note that project is the outlier for how much code it contained. That team did have the most trouble getting things done on time and fixing all the bugs, so they passed the least tests, as one would expect given how much code their design choices required them to write. I think the causality goes from their design to the line count, not from the line count to worse design, they had to write lots of code to implement…
Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
131–140 of 384 posts
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#132I 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…
> 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 experience.
Yes, static types come at an initial cost at initial development time. But they pay that time back in spades. This is exponentially true the larger the code base is (more to keep in one's head), the longer the project lives, and the more people are on it.
Having worked on very large C/C++, Scala and Python projects, when it comes to add a major feature or perform a serious refactor, I always want the static typing and the compiler to inform me when I've missed something. Far too many times has code been checked into a large Python code base that breaks something (completely unbeknownst to the programmer), because there's a code path that's rarely executed or arguments to a function flipped, etc.
That all said. There are major benefits to being able to prototype very quickly in a dynamically typed language, too.
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#133Earlier quoted context omitted.
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.
I think most people would consider 20% basically within the margin of error induced by stylistic and other non-meaningful differences. For example, it's not completely clear from the post but it seems like the 0.5x figure is from wc -l, which means Python wins a line every time there is a conditional or loop just because it doesn't need a closing brace. That alone might eat up a lot of the 20%, but you would be hard…
The reason I think this is "big big news" is I thought the general consensus had already been reached in academia if not the programming community that "statically typed functional languages are much better". There's little or no evidence of that in the results of this study.
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#134The 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…
"python doesnt offer a rich standard library" Python is usually considered one of the richest standard libraries out there. Yes, the is no standard way to get this one edgecase, but every language has warts and things like that. It sounds like you are just looking for an excuse to hate on Python.
Sure, but we are talking about the brevity of a language. The richness of the standard library directly impacts brevity.
So, Ruby would have been a better representative (for brevity) of a high-level dynamic-typed language.
> the is no standard way to get this one edgecase
I don't think `.first` is an edge case. It is used fairly often. One example that I can think of right now is when you want to fetch the first row from MySQL. MySQL returns an array, and you would need `.first` to get the first row or null.
> It sounds like you are just looking for an excuse to hate on Python
Not at all. While I don't prefer Python, I recognize there's a downside to a richer standard library. The language becomes more complex; harder to learn.
Richest is relative. If we consider Python against every other programming language, then, yes, it's ONE of the richests.
If we consider Python vs. Ruby vs. Scala, I doubt Python would be considered as richer or richest.
For example, Scala offers a lot of ways to process a list like foldLeft, foldRight, unzip, headOption, lastOption, flatMap, groupBy, and many methods around Map, Set, and etc. There are many examples where Ruby version would result in shorter code like `array.delete_if` and etc. Python probably doesn't offer many of these methods.
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#135Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#136I 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…
Given that they had two Rust versions where one was a third the size of the other, I don't think you should consider that a big result.
I like that the title frames it as a language shootout to pull people in to see if their favorite language wins (and I'm partial to Python having rewritten tens of thousands of lines of Java into numpy). Still, it would be foolish for people to come away from this brilliant analysis by ignoring the more important conclusion.
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#137That was a really interesting article. I completely agree with >>> Abstractions may make things easier to extend in the future, or guard against certain types of errors, but they need to be considered against the fact that you may end up with 3 times the amount of code to understand and refactor, 3 times the amount of possible locations for bugs and less time left to spend on testing and further development. Choosing…
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#138Loved 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…
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#139Earlier 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…
One factor on why Python only saves 20%. Scala has a very rich standard library. Python doesn't. An example is: https://stackoverflow.com/questions/363944/python-idiom-to-r... Ruby would have been a better example of how succinct a dynamic-typed language can be. (I made a similar comment on the parent level.)
Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml
#140I haven't made it through the whole thing yet, but I do want to register a vote in favor of using Lines Of Code count as a rough measure of program complexity. I think it's a perfectly valid things to do, provided that it isn't used as an evaluation metric and nobody is gaming it, and everyone is a reasonably good programmer, not doing crazy things like trying to stuff a massive algorithm onto one line to be clever,…
I'd like to hear others' opinions: There's a guy at my work who loves to use doubly, triply, quadruple-ly nested ternary operators. I always find them super hard to read. Am I just a dunce, or do I have a point in thinking it's unnecessarily terse.