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

241–250 of 632 posts

Re: Diminishing returns of static typing

#241

Post by macspoofing »

mattnewton wrote: post #194
icebraining wrote: post #162

Earlier quoted context omitted.

Typing in Java could be better, sure, but even with its quirks it's way better than the nothing you get with dynamic languages. I disagree; that Java was the standard example of statically typed languages is what convinced me for a long time that I didn't want anything to do with it. Having to pollute my code with all that crap, deal with a lot of dumb restrictions and still have NPEs left me with a sour taste. Only…

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…

Generics in Java have well known limitations stemming from type erasure (a design decision made to preserve backwards compatibility). Things aren't quite as dire as you made them out to be and in the general case, they work quite well.

Re: Diminishing returns of static typing

#242

Post by senorjazz »

cm2187 wrote: post #215
enraged_camel wrote: post #143

Earlier quoted context omitted.

>>There are a class of bugs you just never need to worry about when the compiler does some compile-time checks for you ... like worrying that you passed the wrong type into a function, or the wrong number of arguments. People always say this and it baffles me. Bugs like that should be caught immediately by your test cases. You shouldn't rely on the compiler to catch them for you.

If you have to write a test for every line of code you write, the "chatty" argument against static typing goes away.

and not just that, but for every possible case for the line you can think of. Like the post above, testing the results of a function returns a list for 1 item, or many items...

I see all too often, java bad, just look at how many lines you need to write to get "hello world". Who cares, the IDE generates that for you, but if you don't understand static void main as a beginner... again who cares, just put it in and ignore it until you need to understand it. Also read that dynamic languages are so productive, but they never mention you need to then write tests to detect what the compiler would catch for free. Yes good code needs tests, but the compiler IMO is a damn good built in test suite for catching many classes of errors

Re: Diminishing returns of static typing

#243

Post by joncampbelldev »

dkersten wrote: post #53
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.

For me, what I miss when using dynamic languages is good, solid refactoring tools that can inline functions/methods, rename across source files, etc. In my experience, in both Python and Clojure, the refactoring tools simply don't come close to those of languages like C++, C# and Java. And I say this as a major Clojure fanboy...

Namespaced keywords can really help with refactoring your domain model.

Usually I use normal keywords for throwaway or glue code, but anything important (my actual domain entities) will be namespaced, allowing (relatively) pain free refactoring.

Cursive has a few good refactoring tools/shortcuts, but I would also like to see extract/inline/move for functions.

Re: Diminishing returns of static typing

#244

Post by andrewla »

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…

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"?

Re: Diminishing returns of static typing

#245

Post by woolvalley »

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?

Re: Diminishing returns of static typing

#246

Post by gipp »

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.

Strict use of type annotations has to be a team decision, yes. Checking for them can be integrated into a CI build, though.

The typing spec provides for supplementary "stub files" that can be provided for third-party dependencies without their own annotations. The typeshed project provides these for a fair and quickly increasing number of common dependencies, and is plugged into pycharm and mypy by default: https://github.com/python/typeshed

Re: Diminishing returns of static typing

#248

Post by nradov »

mattnewton wrote: post #194
icebraining wrote: post #162

Earlier quoted context omitted.

Typing in Java could be better, sure, but even with its quirks it's way better than the nothing you get with dynamic languages. I disagree; that Java was the standard example of statically typed languages is what convinced me for a long time that I didn't want anything to do with it. Having to pollute my code with all that crap, deal with a lot of dumb restrictions and still have NPEs left me with a sour taste. Only…

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 ArrayList to any other class which implements the List interface without breaking the program.

Re: Diminishing returns of static typing

#249

Post by fori1to10 »

Tade0 wrote: post #200
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…

Perhaps it's because the languages you mentioned barely register in statistics(aside from Clojure maybe). Maybe it's simply hard to have both a good type system and a friendly learning curve?

The learning curve for Julia is very easy.
Post reply on HN