5 ms·
Is LOC really a significant measurement? Sure you have to type more characters when working with a strictly typed language, but that takes a couple of seconds o
by voidhorse 8y ago
Is LOC really a significant measurement? Sure you have to type more characters when working with a strictly typed language, but that takes a couple of seconds opposed to however long it might take to track down a bug in a massive enterprise system. Not to mention the type system often forces you to consider cases you might otherwise overlook when writing dynamic code, hopefully resulting in better code to begin with—it imposes a bit of discipline.
In my opinion whatever perceived tax a type system entails is superficial—sure, coming from a dynamic language, having to specify types for everything seems like taking on an extra chore—but this is just the surface experience of using a type system—once you’ve used one for a while and furthermore, had the benefit of reading typed code, you really start to appreciate having types around and any so called “tax” involved quickly becomes negligible.
While it might be a “tax” when writing code it’s defintely a boon when reading code—it’s much faster to look at types to get a handle on an api than it is to have to dig through and read the actual implementation to try and decipher what exactly a function expects and returns. When using a Haskell library, for example, I rarely ever have to read documentation extensively or read implementations—looking at the types of functions and a brief description (one sentence) is often sufficient. It takes a couple of seconds. This is the norm with Haskell code. Contrarily, this is an exceptional case for dynamic languages—if the documentation isn’t superb you always wind up having to peek at the implementations at some point—this typically takes longer than glancing at types and a one sentence description.
Dynamic languages might be more “expressive” from a writers perspective (since you can leave out types) but they’re far from expressive from a readers perspective—since the writer convenience often puts the onus of sussing thing out on the reader. In enterprise systems, reader convenience is arguably more important.
- dmitriid 8y ago> Is LOC really a significant measurement? It is. Number of bugs per line of code is nearly the same across languages. So the best way to reduce bugs is to reduce LoC
- zihotki 8y ago1-line Perl programs are looking at this comment with approval.
- m45t3r 8y ago> 1-line Perl programs are looking at this comment with approval. 1-line Perl programs are far from being representative of real systems and generally only exists for code golfing.
- kurtisc 8y ago>Number of bugs per line of code is nearly the same across languages. Has this been studied?
- dmitriid 8y agoI can't give a more complete answer than this SO answer: https://softwareengineering.stackexchange.com/a/185684 https://softwareengineering.stackexchange.com/a/185684 :)
- kurtisc 8y ago15-50 being quite a big range and the 2004 publication date of the book (the comments hint at the reference being earlier) make me reluctant to take it at face value without looking into it in more depth, especially regarding new technology like TS, Rust, or enterprise Haskell.
- dmitriid 8y agoRead it as 1.5-5% of lines contain bugs. In the original post AirBnB said 38% of their bugs could be prevented by static typing. This would bring this to 0.9-3%. Not insignificant, but LoC is still more important.
- okal 8y ago[Citation Needed]?
- dmitriid 8y agoI can't give a more complete answer than this SO answer: https://softwareengineering.stackexchange.com/a/185684 https://softwareengineering.stackexchange.com/a/185684 :)
- dunefox 8y ago> Sure you have to type more characters when working with a strictly typed language You might be interested to hear about type inference.