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

371–380 of 632 posts

Re: Diminishing returns of static typing

#371

Post by mattnewton »

Merovius wrote: post #361
mattnewton wrote: post #15

I just don’t buy that go is some sort of sweet spot because it doesn’t have generics. Generics pretty much exist for maps and slices, because they are needed in real programs. The language designers just don’t let you make your own generic collections.

The fact that maps/slices/channels already exist generically is what puts Go into the sweet spot. You have generic containers for the vast majority of use-cases, so the value-added consideration of being able to cover more use-cases with generic containers becomes a lot smaller. In a hypothetical world where the designers never added the specific containers they did, you'd get a whole lot more value out of generics f…

You have containers for all the use cases the designers thought of, but then you have it worse than Python for all the other use cases, and you are stuck doing code generation or type erasure. It is impractical to expect go’s designers to have foreseen the best trade off for every codebase.

Architecture astronauting can be prevented with best practices and code review, not with language limitations. It’s a fools errand to try, code generation allows you to get all the complexity and more of generics.

Re: Diminishing returns of static typing

#372

Post by nicoburns »

nradov wrote: post #248
mattnewton wrote: post #194

Earlier quoted context omitted.

Agreed, every time I had to patiently explain to javac that shockingly, my new ArrayList was a List , my new FooBar was a FooBar, and always would be, it drove me slowly mad. Still, I was thankful for the static types when trying to understand where this strange object came from and what it was supposed to do. I’m glad we have modern languages that have the potential to do an even better job of that without a lot of…

While it may be frustrating to novice programmers, the distinction between interfaces (List) and implementation classes (ArrayList) is quite valuable, especially when dealing with huge code bases that have to be maintained over decades. Those declarations help to establish an internal design contract and clarify the developer's intent . In this particular case, a future maintenance programmer could switch from ArrayL…

True, but there are more elegant solutions. For example, Rust's traits allow you to define a trait (somewhere in between an interface and an abstract class in Java), and then methods can be generic over any object that implements that trait. And structs and traits have a many-to-many relationship.

This allows you implement patterns like duck typing which are idiomatic in languages like javascript, but impossible to implement in java.

Re: Diminishing returns of static typing

#373

Post by catnaroek »

Lutia wrote: post #335
andrewla wrote: post #244

Earlier quoted context omitted.

It's Camp D that I'm least familiar with here; outside of academic projects in lisp/scheme I've never used them for anything serious. What exactly does it mean to have "good dynamic typing facilities"?

> What exactly does it mean to have "good dynamic typing facilities"? To quote Peter Norvig on the difference between Python and Lisp, but you could apply it to most other mainstream dynamic languages vs Lisp : > Python is more dynamic, does less error-checking. In Python you won't get any warnings for undefined functions or fields, or wrong number of arguments passed to a function, or most anything else at load time…

What does “somewhat sound” mean?

Re: Diminishing returns of static typing

#374

Post by flavio81 »

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 can feel your pain, but note that this isn't a fault of dynamic typing per se. This is bad coding (for example, no good use of modules) plus the problem of Javascript itself having many issues; not to mention the wildly different levels of quality within the JS library ecosystem.

Re: Diminishing returns of static typing

#375

Post by mattnewton »

breischl wrote: post #270
mattnewton wrote: post #194

Earlier quoted context omitted.

Agreed, every time I had to patiently explain to javac that shockingly, my new ArrayList was a List , my new FooBar was a FooBar, and always would be, it drove me slowly mad. Still, I was thankful for the static types when trying to understand where this strange object came from and what it was supposed to do. I’m glad we have modern languages that have the potential to do an even better job of that without a lot of…

Those things are indeed obnoxious, but they are truly _Java_ issues rather than static typing issues. For instance, C# will figure that stuff automatically in many cases using the _var_ keyword. The Lombok plugin can add something like that into Java, although it's only about 80% as good because of other Java limitations, primarily type erasure.

I agree. While I have never used C# in anger I have played with enough other (non-Java staticky typed) languages to know that it doesn’t have to be this bad :D

Re: Diminishing returns of static typing

#376

Post by emodendroket »

girvo wrote: post #367
emodendroket wrote: post #235

Earlier quoted context omitted.

I've been writing PHP for a couple months and I've been pleasantly surprised so I feel like I am moving beyond that.

To be fair, PHP 7.1 with Composer is a very different language to PHP 4, for the better of course.

Yeah, sure, and I was able to avoid the painful years. But C# pre-generics and pre-Linq is a way less appealing language too, you know? Most languages that are popular now look kind of rough to work in several versions ago.

Re: Diminishing returns of static typing

#377

Post by zbobet2012 »

Merovius wrote: post #343
zbobet2012 wrote: post #281

Earlier quoted context omitted.

It depends on your type system. In new languages like Idris or F* you can encode in the type the correctness of an algorithm and it will not compile if the compiler can not prove that correctness. For example I can prove my my string reverse works in Idris ( https://www.stackbuilders.com/news/reverse-reverse-theorem-p... ). Or I could prove that my function squares all elements in a list. Etc. Now a big part of the p…

> For example I can prove my my string reverse works in Idris ( https://www.stackbuilders.com/news/reverse-reverse-theorem-p... ). This article basically demonstrates GP point, though. It proves that `reverse` is self-inverse, but there are lots and lots of functions that are self-inverse (for example, `x -> x` is self-inverse. As would be the function that swaps any odd-index element with the one following it). The…

This is precisely what I said in the next paragraph and even mentioned away to correctly encode that "correctness". Where a _correct_ implementation of reverse has the property `strHead' s = strTail' (reverse s)` recursively.

It's important to understand that type systems can encode correctness to the level you can specify it. So the program is therefore bug-free to the accuracy of your requirements on it.

Most people do not work with type systems which can do this and are unfamiliar with formal verification. The author presents directly (and argues through out) that there is a correlation not that bug free and static analysis are the same thing.

Re: Diminishing returns of static typing

#378

Post by walshemj »

Merovius wrote: post #327
walshemj wrote: post #108

Earlier quoted context omitted.

Also the article does not take into account the much higher cost fixing a bug in live compared to development

It does (though admittedly not very explicitly), it just rolls it into the "benefit" (i.e. not shipping broken code is a benefit) and the "weight given to stability". If a bug discovered in prod (or even qa/canary) has a significantly higher cost than a bug discovered early, that will influence the weight you are putting on stability. In that way, this factor is subsumed in one of the other graphs. As you might've no…

Ty I take the point and it depends on the sort of project your working on a celphone app is different to say a major telcos billing system.

Re: Diminishing returns of static typing

#379

Post by catnaroek »

catpolice wrote: post #106

Static typing prevents bugs in code to the degree that the programmer can correctly encode the desired behavior of the program into the type system. Relatively little behavior can be encoded in inexpressive type systems, so there's a lot of room for bugs that have nothing to do with types. A lot more behavior (e.g. the sorts of invariants mentioned in agentultra's top level comment) can be encoded in a more expressiv…

> but you get more assurances when your type system gives you feedback about whether you're thinking about the problem right.

It really isn't as much about languages as it is about the people who use them. The key ability is to prove things about programs. Powerful type systems, especially those that have type inference, merely relieve the programmer from some of the most boring parts of the job. Sometimes.

Re: Diminishing returns of static typing

#380

Post by thesz »

millstone wrote: post #63
thesz wrote: post #45

The effort to fix a defect is proportional to the time between introduction of a defect and it's discovery. This is a basic intuition behind all good practices, including CI, QA, etc. Types allow one to discover program defects (even generalized ones, when using some of the programming languages) in (almost) shortest possible amount of time. Types also allows one to constrain effects of various kind (again, use good…

Also, retaining dynamic types at runtime enables you to find type errors that the static type system could not discover, or that were worked around. Language implementations that discard dynamic types make it harder to find defects.

Algebraic data types allow you to get any amount of dynamism you would needed.

Have you familiarized yourself with Haskell?

Post reply on HN