Diminishing returns of static typing • Hacker News Board

Re: Diminishing returns of static typing

#541

Post by Eridrus » Tue, Oct 03, 2017, 11:33 AM UTC

hinkley wrote: post #341

Eridrus wrote: post #35

Earlier quoted context omitted.

I think dynamic typing proponents get hung up on the auto-complete aspect. The real benefit is when you find someone writing a property with a common-ish name to a data structure and you want to know "who the hell uses this", you can answer that question pretty easy in statically typed languages. In dynamically typed languages you kind of just grep and hope the name is not too common.

I work with an in-house framework written in Javascript. You would think by looking at the code that the creators had a 30 word vocabulary, because 80% of the code uses the same six nouns and four verbs to pass data around and what you use those for depends on the context of who is calling it. Oh, but the entire thing is written using promises, so most of your function calls have no context. It's hell, and I'm starti…

I don't think Node is doomed; Typescript + async/await makes code make sense.

Re: Diminishing returns of static typing

#542

Post by danmaz74 » Tue, Oct 03, 2017, 11:34 AM UTC

deepGem wrote: post #488

zmmmmm wrote: post #419

Earlier quoted context omitted.

> For any code base that isn't a throwaway like a one-off script or similar, say 10 or 20 years maintenance I think one of our problems is that people have downgraded the importance of this. Much code nowadays (rightly or wrongly) is considered "disposable" - people think that the likelihood of any given piece of code they are writing as surviving more than a few years is negligible. It is a natural assumption when y…

And half the reason we keep throwing code away is because it was created without consciousness of maintainability. Well, this has nothing to do with static vs dynamic typing. You can write unmaintainable code in static languages very easily. In startups, developers often overlook maintainability, I completely agree but that's because everyone knows that the code you are writing today might not be needed 2 years down…

It's also caused by the fact that nowadays a lot (most?) of the code that gets written is for the web or mobile, where technology changes incredibly fast.

Re: Diminishing returns of static typing

#543

Post by Eridrus » Tue, Oct 03, 2017, 11:36 AM UTC

flavio81 wrote: post #49

Eire_Banshee wrote: post #41

Earlier quoted context omitted.

This. Not just, "who the hell uses this", but "where the hell is this defined" as well.

>Not just, "who the hell uses this", but "where the hell is this defined" as well. On Common Lisp, a dynamic language, I can also get this answered instantly. I just press a key combination on a method call and i jump to the definition. So this isn't exclusive to statically typed languages.

I think it's telling that while there are Lisp aficionados in this thread telling us how great it is, none of these ideas have been implemented in Python or JavaScript or Ruby, the most common dynamically typed languages.

And that's really all I care about, I'm not about to start writing production code in Lisp.

Re: Diminishing returns of static typing

#544

Post by catnaroek » Tue, Oct 03, 2017, 11:38 AM UTC

klibertp wrote: post #511

catnaroek wrote: post #487

Earlier quoted context omitted.

Contracts are useless. They merely describe what you want your code to be, not what your code actually is. Just grab a pen and a piece of paper, and start proving things about your programs.

> Contracts are useless. No, they are not. 1. If the code doesn't conform to the contract, it will fail on the contract boundary, with a well-defined error. If this is useless, then `assert` is also useless, which it is, of course, not. 2. With a sufficiently well-designed language and sufficiently smart compiler, you can move some contract checks to compile-time. See Racket. 3. If your language supports both static…

0. Trapping the error doesn't make your program any less wrong. I agree that `assert` is equally useless.

1. With pencil and paper, you don't need to wait for a smart compiler - you can get started proving things about your programs today!

2. I can totally see what's coming next: “Being wrong is dual to being right, so being wrong is another possibility worth exploring”. Right?

> Meta: (slander)

No comment.

Re: Diminishing returns of static typing

#545

Post by ajdlinux » Tue, Oct 03, 2017, 11:39 AM UTC

irrational wrote: post #468

alkonaut wrote: post #265

There are 3 main areas of interest in the discussion of benefits of static vs dynamic typing. - Quality (How many bugs) - Dev time (How fast to develop) - Maintainability (how easy to maintain and adapt for years, by others than the authors) The argument is often that there is no formal evidence for static typing one way or the other. Proponents of dynamic typing often argue that Quality is not demonstrably worse, wh…

10-20 years?! Holy Cow! Other than huge software projects (like Word or Mac OS - and even then...) is there really software that still has that kind of maintenance window? I've worked for a Fortune 150 company for nearly 2 decades. There is not a single piece of software at the company that has not been rewritten from scratch (usually due to business changes) at least once every 10 years. I can't even imagine somethi…

I also work at a similarly large company.

Some of our internal infrastructure systems are 10-20 years old - some could definitely do with a complete rewrite, but in the meantime, they're mission critical systems.

As for our products - some of them have even longer timeframes than 20 years.

Re: Diminishing returns of static typing

#546

Post by rndmio » Tue, Oct 03, 2017, 11:43 AM UTC

erfgh wrote: post #529

danharaj wrote: post #28

Earlier quoted context omitted.

List typing isn't as superficial as it seems. The following has happened to me multiple times, perhaps in the last month : I have a large code base. I want to replace a fundamental data structure to support more operations/invariants/performance guarantees. I change the type at the roots of the code base. My instance of ghcid notifies me of the first type error. I fix it. This repeats until the program compiles again…

> This is insane in Python/C/Ruby. It's only insane if you don't have test cases with good coverage, in which case you are very-very-very screwed, statically typed or not.

Testing is not the answer to the problem of knowing if I refactored everywhere necessary. In a statically typed language I don't even have to worry about what do I do if my function is passed a var of the wrong type, it won't compile.

Re: Diminishing returns of static typing

#547

Post by crdoconnor » Tue, Oct 03, 2017, 11:51 AM UTC

macspoofing wrote: post #531

crdoconnor wrote: post #333

Earlier quoted context omitted.

Decent programmers compose code bases of "significant size" from many small, loosely coupled single purpose applications. Yes, IME it's still quicker. OTOH, if you're using "codebase of significant size" as code for "big ball of mud", static typing certainly helps, but integration tests are the real lifesaver.

>OTOH, if you're using "codebase of significant size" as code for "big ball of mud", static typing certainly helps, but integration tests are the real lifesaver No. I mean when the codebase is of a certain size, new features require some thought and planning. Features may span multiple-modules. They may require partial or full rewrites or the refactoring of any number of sub-components to support the new behaviour. T…

>No. I mean when the codebase is of a certain size, new features require some thought and planning. Features may span multiple-modules. They may require partial or full rewrites or the refactoring of any number of sub-components to support the new behaviour. This means that you proceed carefully because you may not want to introduce regression bugs. This costs time.

Yes. And all equally true for statically typed languages.

Refactoring without tests is easier in a statically typed language, but still stupid. If you assume a decent body of tests, the benefit dissipates quickly.

If you prototype faster, as you usually will in a dynamically typed language, your design mistakes cost less. Since in large software systems I tend to find that the two biggest sources of bugs are a) errors in specification and b) poorly designed APIs, not obscure edge case bugs, quicker prototyping helps in large projects too.

And, if your design is solid, you can still achieve similar benefits as static typing by "locking down" your boundary code with asserts so that future development that interacts with that boundary code will fail quickly if it interacted with in the wrong way.

>At that point, you're not limited by your typing speed as you may be putting in net 10 lines of code a day. There is just no benefit to dynamic typing at that point.

This is fallacious. You're never limited by your typing speed in any language at any point. The cost of "extra typing" is cognitive, not a finger speed limitation.

The benefit of dynamic typing is more flexibility in the code you write (especially useful for writing frameworks and such) and quicker turnaround when prototyping because you do not have to prespecify as much up front.

Re: Diminishing returns of static typing

#548

Post by mobiletelephone » Tue, Oct 03, 2017, 11:55 AM UTC

flukus wrote: post #426

mikeash wrote: post #405

Earlier quoted context omitted.

It's not just that void * exists, but that it's basically mandatory. C's built-in arrays are super weak, so you need some library to do proper resizable arrays. Since C doesn't have generics, such a library will use void * as the type for putting values into the array and getting them back out again. You'll be casting at every point of use, and nothing will check to make sure you got the cast right, other than runnin…

> C's built-in arrays are super weak, so you need some library to do proper resizable arrays. Since C doesn't have generics, such a library will use void * as the type for putting values into the array and getting them back out again. You'll be casting at every point of use, and nothing will check to make sure you got the cast right, other than running the code and crashing. There are other options though like macros…

I use a code generator. It has a great type system, it's composable, mature and it can even compile pretty fast with the right tooling. It's called C++!

Re: Diminishing returns of static typing

#549

Post by kerkeslager » Tue, Oct 03, 2017, 11:58 AM UTC

Sir_Cmpwn wrote: post #268

danharaj wrote: post #28

Earlier quoted context omitted.

List typing isn't as superficial as it seems. The following has happened to me multiple times, perhaps in the last month : I have a large code base. I want to replace a fundamental data structure to support more operations/invariants/performance guarantees. I change the type at the roots of the code base. My instance of ghcid notifies me of the first type error. I fix it. This repeats until the program compiles again…

I don't really the lumping of C in with Python and Ruby here. The C compiler picks up on that, too. All over this comment section people are calling C weakly typed, I don't get it. Is it because void* exists? Every language has something like that.

In this thread, a.lot of people are conflating strong/weak typing with static/dynamic typing.

Static typing versus dynamic typing is fairly binary: if your types are checked at compile time they're probably static, while if they're checked at run time they are probably dynamic. Haskell, C are statically typed, Python, JavaScript are dynamically typed.

Strong/weak typing is more of a spectrum. A strong type system can check many properties of programs and accommodate many patterns as types. A weak type system, on the other hand, can't check many properties of programs, and has to be bypassed to accommodate common patterns. JavaScript has probably the weakest type system, because it checks almost nothing ("hi" + 42 returns "hi42" even though this is nonsensical, {}.foo returns undefined rather than throwing a type error). C is fairly weakly typed because you can add disparate types (int* + int returns int* even if you intended to add two integers) and the type system has to be bypassed with void* to do anything sizeable. Python, ironically, is slightly stronger, in that applying operators to objects of types with no defined relationship throws exceptions ("hi" + 42 errors). A spectrum from weakest to strongest might look something like: JavaScript, C, Go, Ruby, Python, Java, C#, OCaml, Haskell.

My personal experience is that the difference between static and dynamic types isn't very important to my development process or code quality. I have to run and unit test my code to verify it, so the checks happen regardless of whether they happen at compile time or run time. But the difference between strong and weak typing is huge. Strong types catch more bugs, but perhaps more importantly, they catch those bugs where they occur. A type error when adding "hi" + 42 is far more useful for debugging than a mysterious unit test failure on a completely different function where it's returning "Hi42username" instead of "Hi Username" because you added the wrong variable. A segfault 30 lines later is harder to debug than an error when trying to add an int to the value at an int*.

Re: Diminishing returns of static typing

#550

Post by narimiran » Tue, Oct 03, 2017, 12:01 PM UTC

ztjio wrote: post #526

alkonaut wrote: post #265

There are 3 main areas of interest in the discussion of benefits of static vs dynamic typing. - Quality (How many bugs) - Dev time (How fast to develop) - Maintainability (how easy to maintain and adapt for years, by others than the authors) The argument is often that there is no formal evidence for static typing one way or the other. Proponents of dynamic typing often argue that Quality is not demonstrably worse, wh…

My first big love in languages was Turbo Pascal, because, it was the first one I learned. So many people do this, fall in love with the first language they understand. My second big love in languages was Python. It's also the language in which I wrote my first major software product. It was this product that taught me to hate Python. Not because it was hard to create, or because quality was low. In fact, I was VERY F…

> Sadly now I'm moving into the data science/data engineering field and everything is Python and I don't know. I don't want to go back to this nightmare.

Now there are (optional) type annotations and mypy [0]. I've been using them in my latest projects and I found them useful/helpful.

[0] http://mypy-lang.org/