Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Diminishing returns of static typing

blog.merovius.de

Post reply on HN
Print view View original

551–560 of 632 posts

Re: Diminishing returns of static typing

#551

Post by crdoconnor »

humanrebar wrote: post #538
ex_amazon_sde wrote: post #535

Earlier quoted context omitted.

> I can't even imagine something that would still be useful after 10 years Ah the HN perception bubble. Good code last longer than that. Bad code gets replaced.

Good code is replaceable. Bad code is hard to get rid of. Some code sticks around because it's great at what it does. Some code sticks around because it works if you don't touch it and is impossible to delete due to various kinds of dependencies.

All code is replaceable. It's bad APIs that are hard to get rid of.

Most POSIX APIs, for instance, are confusing, obtuse and unnecessarily imperative but still good enough in spite of being 40 odd years old. There's way too much code that implements or calls them to justify making significant changes as this point.

Re: Diminishing returns of static typing

#552

Post by collyw »

ex_amazon_sde wrote: post #535
irrational wrote: post #468

Earlier quoted context omitted.

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 can't even imagine something that would still be useful after 10 years Ah the HN perception bubble. Good code last longer than that. Bad code gets replaced.

If it ain't broken, don't fix it.

Re: Diminishing returns of static typing

#553

Post by sitkack »

tree_of_item wrote: post #466
kobeya wrote: post #460

Earlier quoted context omitted.

You mean like this: http://hackage.haskell.org/package/hotswap Or this: http://hackage.haskell.org/package/dyre

15 commits 4 years ago, 121 commits 8 months ago If these things are so good why does no one use them? EVERYONE using Erlang is using the same hotswapping facility. This sort of dynamism is just fighting against the language in an environment like Haskell.

Hot code reloading isn't used in practice to much extent in Erlang codebases either. It exists, in my experience mostly for Dev or emergency patch but not for normal release upgrades. Dynamics with tagged values and pattern matching def make Erlang the easiest to hot reload.

Re: Diminishing returns of static typing

#554

Post by suprfnk »

hellofunk wrote: post #209
fny wrote: post #88

There's one huge benefit to static typing people often forget: self documentation. While, yes, top-quality dynamic code will have documentation and test cases to make up for this deficiency, it's often still not good enough for me to get my answer without spelunking the source or StackOverflow. I feel like I learned this the hard way over the years after having to deal with my own code. Without types, I spend nearly…

Many dynamically typed languages offer excellent runtime contract systems (Racket, Clojure) that serve as an implicit documentation at least as well as a statically-type language. Often more so, because you can express a lot of things in contracts that are not easily expressed in type systems.

> because you can express a lot of things in contracts that are not easily expressed in type systems.

Can you give an or some example(s) of this?

Re: Diminishing returns of static typing

#555

Post by ex_amazon_sde »

humanrebar wrote: post #538
ex_amazon_sde wrote: post #535

Earlier quoted context omitted.

> I can't even imagine something that would still be useful after 10 years Ah the HN perception bubble. Good code last longer than that. Bad code gets replaced.

Good code is replaceable. Bad code is hard to get rid of. Some code sticks around because it's great at what it does. Some code sticks around because it works if you don't touch it and is impossible to delete due to various kinds of dependencies.

We are talking years and decades, where "replacing" is applied to entire applications, not chunks of code.

Especially in SOA, it can be cheaper to replace a poorly written service than trying to rewrite all of it over time.

Re: Diminishing returns of static typing

#556

Post by falsedan »

zmmmmm wrote: post #419
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…

> 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…

> people think that the likelihood of any given piece of code they are writing as surviving more than a few years is negligible

Well, most code is written by relatively-inexperience developers, who have not had to retire a system or support a legacy one, and don't know what should be sought out & what should be avoided when designing a system. Thus, they make decisions with limited information to solve the problem at hand, and only later find out the implications of those decisions when someone wants to (say) deploy it as a dockerized service on k8s.

It's one thing to read The Mythical Man Month, and another to write a replacement system that stops providing business value after 30 months and needs to be rewritten to support the current needs.

> it is so easy to say that the last person's code was garbage, so we are going to rewrite it because that is faster than understanding and then fixing the bugs in what they wrote

There's no black and white answer here: sometimes the code is so convoluted (or in the wrong language) that it has to be rewritten; sometimes the design of the system strongly resists changes in behaviour & so much of it needs to be made more flexible that an incremental improvement would cost about the same as a full rewrite.

Re: Diminishing returns of static typing

#557

Post by falsedan »

collyw wrote: post #552
ex_amazon_sde wrote: post #535

Earlier quoted context omitted.

> I can't even imagine something that would still be useful after 10 years Ah the HN perception bubble. Good code last longer than that. Bad code gets replaced.

If it ain't broken, don't fix it.

> If it's broken but in familiar, known ways, with runbooks, and the cost of rewriting it is way higher than supporting it for 5 years & hopefully we'll move away from the business model which requires it, don't fix it.

Re: Diminishing returns of static typing

#558

Post by agentultra »

fabioz wrote: post #424
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 find that people doing these claims have seldomly really worked in large Python codebases... Personally, I find it pretty workable in Python with a big codebase (but you have to respect the rules like having a good test suite -- you change the time from compiling to running your test suite -- which you should have anyways)... I find that the current Python codebase I'm working on (which has 15 years and around 15k…

I'd worked in OpenStack for 4 years and with Python in general for about 10 years.

I can say from my experience it is definitely possible to maintain large codebases in Python. The type errors of the superficial variety that the OP refers to were usually caught before they made it to production (and were rare besides if you were experienced enough to avoid them). It requires discipline to maintain tests and write code in a way that avoids errors.

I've been learning OCaml and Haskell for a couple of years along with formal methods using TLA+ and Lean. I used to think type theory was the accounting of maths. I still think that's at least partly true but the power it brings you as a programmer is quite powerful.

I find working with Haskell or OCaml to be much more productive. Instead of stepping through a debugger or following tracebacks (a descriptive error) I get prescriptive errors as I make changes to a Haskell codebase. The propositions in the type system form a much better specification than unit tests alone.

I still like Python and C for many reasons and will continue using them where appropriate. However I think Haskell/OCaml offer quite enough power that everyone should at least consider what they bring to the table.

Re: Diminishing returns of static typing

#559

Post by oldandtired »

zzbzq wrote: post #452
oldandtired wrote: post #429

It has been interesting to see the to and froing of arguments for and against static typing in the discussions here. Though I am not a type theorist (I only dabble in compilers and language design), I have noted that many people conflate static typing and dynamic typing with other additional ideas. Static typing has certain benefits but also has certain disadvantages, dynamic typing has certain benefits but also has…

Maybe part of the problem is I can't picture what you're actually talking about with soft typing. I can tell you C#/.NET has the DLR which allows you to do dynamic types whenever you want. Outside of a few gimmicks, you rarely see these used. I've rarely even seen them for quick prototyping, because generally you mess around with using them for prototying, then the first time they go bad, it's really obnoxious, and y…

Soft typing could be characterised by having the compiler do static type analysis where it can, but leave the type analysis to the runtime when it can't.

A simple example of this is a list. Now in statically typed languages, list are homogeneous (this is includes type unions). In dynamically typed languages, list can be heterogeneous, essentially anything can be added at runtime.

In soft typing, we can indicate that a list is homogeneous and the compiler will ensure that this is true or we can specify no type checking (as such) and this will be done at runtime.

Contrived yes, but I regularly use other aggregates (tables and sets) into which I do not want them to homogeneous.

One of the aspects that I like about functional languages is the polymorphism available, but in all that I have come across, there is no way to make a tree or list heterogeneous without declaring union types before hand.

My problem with C#, C++, Java, and their ilk, is that code is multiplied with their generics.

How the IDE and compiler and type systems interact is a design function and is not inherent to any type system.

One of the reasons I don't use specific main stream languages such as C#, C++ or JAVA is that they don't provide the specific programming features that I desire.

I have looked at Go, Swift and Rust and I am not at all impressed by the "relative stupidities" within those languages. For other programmers, what they consider to "relative stupidities" is entirely up to their experience and outlook.

Re: Diminishing returns of static typing

#560

Post by yogthos »

rbobrowicz wrote: post #421
yogthos wrote: post #351

Earlier quoted context omitted.

A lot of the same refactoring is possible in dynamic languages as in static ones. I recommend reading up on Term to see what's possible to do with JavaScript http://marijnhaverbeke.nl/blog/tern.html I use Cursive https://cursive-ide.com/ for working with Clojure, and it can do safe refactoring for symbols by doing static analysis of the source. It can show all usages of a symbol, rename it, do automatic imports, and…

For someone only passingly familiar with Spec, what's the benefit of Spec over just using a property based testing framework like Haskell's QuickCheck (and I think Clojure's test.check)? I can encode all those invariants as QuickCheck properties and have them automatically tested against random inputs on every test run. It's still all runtime verification, but with random inputs I actually have more confidence of hit…

To add to what sheepmullet said, I think the insertion sort example is exactly the problem with advanced type systems. It takes nearly 300 lines of code to provide the specification.

Somebody has to be able to read that specification and understand that it's correct in a semantic sense. Ultimately, the specification itself becomes a full blown program that the type checker executes. So, now you run a program to try and verify aspects of your original program, but how do you verify that the specification itself is correct?

At some point a human has to be able to read the code and decide that it matches the intent. This step can't be automated, and I certainly don't think the Idris example improves things. I'd argue that it's far easier to tell that this version is correct:

    fun insertionSort(arr, int n)
    {
       var i, key, j;
       for (i = 1; i = 0 && arr[j] > key)
           {
               arr[j+1] = arr[j];
               j = j-1;
           }
           arr[j+1] = key;
       }
    }
Post reply on HN