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

271–280 of 632 posts

Re: Diminishing returns of static typing

#271

Post by flavio81 »

danharaj wrote: post #18

Just a technical point that hints at a significant philosophical idea: The asymptote cannot reach 100% of program behavior in any finitary way. That would solve the halting problem. The x-axis should go off to infinity. Also, it's not a smooth progression. There are huge jumps in expressivity involved here. Going from Java-style types to Hindley-Milner to full System F are all massive jumps in expressivity. There are…

>How many ways are there to do something in lisp?

Many. That's the whole point -- to let you choose "the way to do something" that applies the best to your circumstances (development time, performance, allowable complexity, etc.)

So you are limited by your own mind and skills -- not by the language.

Re: Diminishing returns of static typing

#272

Post by yawaramin »

nightski wrote: post #227
y4mi wrote: post #226

Earlier quoted context omitted.

> I still write 90% of my useful code in python, but that one week of debugging was exhausting & basically wouldn't have even compiled in a statically declared language.[...] nothing stops you from using static typing with python3

I haven't used optional typing in python. However, the problem I see with optional typing is that while I may choose to use it my team mates might not. Even more importantly, the 3rd party dependencies I use probably don't. So the amount of code that actually uses the types would be very limiting. Saying the choice is entirely up to you personally is a misnomer.

I think GP meant 'you' as in 'your team'. Anyway, Python has a type repository for popular libraries, just like TypeScript does. And mypy can still typecheck your code even without type annotations.

Re: Diminishing returns of static typing

#273

Post by mattnewton »

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…

It’s not about having the difference, it’s about having to explain to Javac what I am using because it’s incapable of doing meaningful type inference.

Re: Diminishing returns of static typing

#274

Post by alkonaut »

Inityx wrote: post #221
flavio81 wrote: post #148

What amuses me in all "static typing versus..." discussions, is that it usually it is the comparison between two camps: Camp A: Languages with mediocre static typing facilities, for example: -- C (weakly typed) -- C++ (weakly typed in parts, plus over-complicated type features) -- TypeScript (the runtime is weakly typed, because it's Javascript all the way down) Camp B: Languages with mediocre dynamic typing faciliti…

Where's Rust in here?

Category C

Re: Diminishing returns of static typing

#275

Post by richdougherty »

woolvalley wrote: post #245
flavio81 wrote: post #148

What amuses me in all "static typing versus..." discussions, is that it usually it is the comparison between two camps: Camp A: Languages with mediocre static typing facilities, for example: -- C (weakly typed) -- C++ (weakly typed in parts, plus over-complicated type features) -- TypeScript (the runtime is weakly typed, because it's Javascript all the way down) Camp B: Languages with mediocre dynamic typing faciliti…

So where does Java & C# fit in those categories?

Probably Camp A. They have some static typing, but it's pretty basic. Then again, according to the article posted, they may be in the "sweet spot" for many purposes.

Re: Diminishing returns of static typing

#276

Post by coding123 »

I'm converting a codebase of Javascript of about 200+ js files to Typescript today. I am about 5% complete... already found two places where the argument list was wrong and was being sent into a void. I also see the code that was making up for the fact that the third argument was being ignored (basically patching downstream because they thought the feature was broken).

Now this codebase was written with a high degree of quality (it's pretty good but not perfect), but the lack of compile (and of course runtime)-time checks has caused waste.

The second phase of my project to convert all promises to RX Observables :)

Re: Diminishing returns of static typing

#277

Post by richdougherty »

flavio81 wrote: post #148

What amuses me in all "static typing versus..." discussions, is that it usually it is the comparison between two camps: Camp A: Languages with mediocre static typing facilities, for example: -- C (weakly typed) -- C++ (weakly typed in parts, plus over-complicated type features) -- TypeScript (the runtime is weakly typed, because it's Javascript all the way down) Camp B: Languages with mediocre dynamic typing faciliti…

Languages like TypeScript and Racket are also interesting because they let you shift camps partway through the project - you can start of untyped and then add typing annotations.

https://en.wikipedia.org/wiki/Gradual_typing

Re: Diminishing returns of static typing

#278

Post by muricula »

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.

void * is part of it, but you can also implicitly cast from between integer types, and also between integers and enums. Think of passing an enum or an int into a function which takes a long as an argument.

Re: Diminishing returns of static typing

#279

Post by bandrami »

gopalv wrote: post #201
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.

> In dynamically typed languages you kind of just grep and hope the name is not too common. For four days, I spent debugging a python production script because in one place I had typo'd ".recived=true" on an object and just couldn't understand why my state machine wouldn't work. And very quickly, the whole team became fans of __slots__ in Python. I still write 90% of my useful code in python, but that one week of deb…

Is that really a typing problem, though? If I tried to use a "recived" slot on a Lisp struct that only had a "received" slot defined, I'd get a read-time error, and there's zero typing involved there.

Re: Diminishing returns of static typing

#280

Post by catnaroek »

lopatin wrote: post #89
namelost wrote: post #40

Earlier quoted context omitted.

Yeah far from finding a sweet spot, Go exists in some kind of type system ghetto, because its type system is so crippled users have to resort to code generation (go generate). Neither Python nor Java programmers have to do that.

Yeah Go is weird in that its static type system doesn't to provide you with great static typing power but instead it's just there as a sort-of sanity checker. If there's logic, they say write it with data structures and functions. Have invariants? Enforce them yourself. If Go is annoying with how little power it provides, that's fair, but other type systems can be just as annoying then, because when given the ability…

> Besides, code generation isn't all that bad.

It is the number one thing that makes C++ templates unusable: semantics defined by means of code generation.

Post reply on HN