Live data from Hacker News

Diminishing returns of static typing

blog.merovius.de

501–510 of 632 posts

Re: Diminishing returns of static typing

#501

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…

Everything that controls hardware has tremendous maintenance windows. Trains, planes, industrial machines.

Most business critical software like SAP for example is also based on decade old codebases.

Re: Diminishing returns of static typing

#502
post #296
post #283

Earlier quoted context omitted.

> Macros are quite orthogonal to this. You ain't gonna to find any sane way to combine macros with a powerful type system in a way the doesn't make a 140+ IQ a requirement for any programmer touching the code using these features in a real world project... Problem with programming language design is that the ideal/Nirvana solutions lie at the edge, or beyond, the limits of human intellect. If you want something that…

There is a programming language property called Restrictability - it means that you only need to know a subset of the features the language provides to become productive. The best languages have high restrictability without compromising on the high level features like powerful macros. The point of having macros is that they allow you to solve problems that cannot be solved elegantly in any other way. But 95% of progr…

But then you don't have real macros. Real macros, as in Lisp macros, are good because they aren't experts-only. Macros are used by all Lisp programmers, all the time, and they're just another tool in the basket.

Re: Diminishing returns of static typing

#503
post #13
post #3

The benefit of static typing isn't just reliability. Tooling is another major argument. Won't appeal to certain hardcore programmers who think that even notepad has too many features. But it is great for refactoring, finding all references to a function or a property or navigating through the code at design time. Basically all the features visual studio excels at for .net languages. And I disagree with the barrier to…

IMO the autocomplete argument is rather unconvincing. Every dynamic language I've worked deeply with has powerful and simple introspection capabilities, and they generally come with much more interactive development environments (shell/REPL), so I've never found API discoverability to be any worse than statically typed languages, just different. In general though, the more you can formally reason about the program, t…

In my mind, what swayed me towards static typing languages was after I played around with Haskell and was able to use the 'deriving' clause.

The realization that with types, smart enough compiler can implement interfaces for me, was amazing.

Unfortunately, I am afraid that it will take a while for these techniques to go mainstream. A.f.a.i.k most a mainstream language can do, is to fill in the method stubs for you.

Re: Diminishing returns of static typing

#504
post #12

The biggest issue with claims like "there are only diminishing results when using a type system better than the one provided in my blub language" is that it assumes people keep writing the same style of code, regardless of the assurances a better type system gives you. "I don't see the benefit of typed languages if I keep writing code as if it was PHP/JavaScript/Go" ... OF COURSE YOU DON'T! This is missing most of th…

Optional typing has not failed in Clojure, it's growing with clojure spec

Re: Diminishing returns of static typing

#505

Earlier quoted context omitted.

In my experience, the time saved from writing in a statically typed language where the compiler catches the bugs for you is made up by having to work more closely with the compiler, typically write more code (type annotations and other things) and in general spend that same time on compile-time rather than run-time bug hunting. Dynamically typed languages typically involve a lot less code, which is time gained. That…

May I ask what your experience of statically-typed languages has been? I find that most people have had a common experience where they didn't get to work in tandem with a fast compiler and a succinct language which inferred most or all types for them, and so their perceptions are coloured by that.

Swift, C++, Haskell (a little), Elm (more than a little)

Re: Diminishing returns of static typing

#506

There is one aspect to this debate that is worth pointing out. What about generative testing, which is possible in static or dynamically typed languages? The article mentions that testing is perhaps more important in a dynamically typed language since there is less compiler support. But for example, Clojure rolled out the very clever Clojure.spec library that allows you to precisely specify all details relating to fu…

Clojure.spec is very clever, but it can be exactly duplicated in a statically-typed language by unit or property testing. It doesn't bring anything to the table that is totally a superset of static typing. > In such a case, the line between these two type environments narrows. Not really. Static types still offer you total proofs of the properties you encode as types, not just experimental results of tests.

Generative testing is just one application of Clojure.spec. It does more than just aid in testing. It doubles as a runtime contract system, a data coercion system, and some folks are using it for compile-time checks as well (not in the testing sense, though I haven't read up on how they are doing that).

It is not a proof-like system, but outside of dependent typing, static typing does not catch value-related bugs, but Clojure.spec can. In a static type system, how easily would it be to exactly specify and guarantee that a function's second parameter is of a higher value than its first, or that a function's output is an integer between 5 and 50, etc? Clojure.spec is just predicate functions composed together to define the flow of data in a program, and those compositions can be used in a variety of ways.

Re: Diminishing returns of static typing

#507

Earlier quoted context omitted.

That's not a useful notion of type. If I cannot tell statically by inspecting a register name nor dynamically by inspecting a bit pattern whether a given register holds a pointer or an integer or a floating-point value, that's pretty much the definition of "untyped".

Dynamic type testing or introspection is not an essential feature of type systems. The fact is, your computing machine is typed. You can not deference a floating point register as an address, for instance.

> Dynamic type testing or introspection is not an essential feature of type systems.

I didn't say so. An essential feature of type systems is being able to determine the types of (many) values, statically or dynamically.

> You can not deference a floating point register as an address, for instance.

So you'd agree that architectures that don't make a distinction between integer and floating point registers are untyped? But sure, call this a type system if you must. It's just a very very weak one, so weak as to be almost entirely useless. (And the reason floating point registers are often separate from integer registers is not to provide this kind of "type safety", it's due to history and architecture.)

Re: Diminishing returns of static typing

#508

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…

4. Performance. There is software that can't be slow.

Right - I was trying to avoid runtime considerations and keep it on language, but it's true there are some concerns that extend into language. The border is becoming fuzzier when you consider that many (most?) languages these days can run in a browser after some transformation. Some even have 3 or more runtimes including js, a managed runtime, or native.

Re: Diminishing returns of static typing

#509

Earlier quoted context omitted.

But dynamically languages give you generic collections and data structures for free. Why would you need static types at all?

They emphatically do not. Ignoring types doesn't give you a type system "for free"; much the same way that building a shelf doesn't make you a librarian.

Dynamically typed systems don't "ignore types", they just handle them at runtime.

Re: Diminishing returns of static typing

#510
post #455

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…

> you can't make good experiments with those time frames Multi-decadal longitudinal studies are not too uncommon in medicine, epidemiology and psychology. Why there is no will to conduct, or fund, this kind of research in computer science, I am not sure. https://en.wikipedia.org/wiki/Longitudinal_study

It's hard to find N projects that are comparable and live for that long. Not least because whatever effect you are seeking will be much less noticeable than e.g differences in developer skill and experience.
Post reply on HN