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

361–370 of 632 posts

Re: Diminishing returns of static typing

#361

Post by Merovius »

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 for containers. But it turns out, the designers used what seems on the surface like a kludge to get most of the benefits, while saving most of the cost. It's a perfect embodiment of the kinds of tradeoffs I'm talking about.

Re: Diminishing returns of static typing

#362

Post by stagger87 »

geofft wrote: post #118
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.

What are your favorite tools for doing this in C/C++ (which are extremely statically typed, if not very strongly typed)? I think the best thing I've found for this personally is coccigrep, which works but I've only used it a couple of times. I'd like something I'd reach for about as often as I reach for grep. (Also I think these days you'd want it to be based on clang or something.) One thing that does seem to be tru…

QtCreator

Re: Diminishing returns of static typing

#363

Post by willtim »

mpartel wrote: post #158
willtim wrote: post #115

Earlier quoted context omitted.

In retrospect, HKTs are arguably Haskells greatest innovation, enabling extremely general abstractions and huge amounts of code reuse.

In my subjective opinion, Haskell has taken abstraction way past the point of diminishing returns, at least for the problems I tend to work on. A large portion of advanced Haskell type system features seem to be about emulating things you could do with side-effects. I guess I prefer Rust's approach to managing side-effects, or even just Scala's implied convention of: use 'var' very sparingly, and mostly locally. Yes,…

As a counterexample, C# needed expensive language extensions to accommodate both LINQ and Async/await. Both can be implemented in Haskell purely as a library, thanks to HKTs.

Both Java and C# tend to rely heavily on frameworks such as Spring to workaround issues with the expressivity of the languages. This causes problems when one needs two frameworks (they don't in general compose). In Haskell, HKTs allow one to write polymorphic programs that are parametric with respect to certain behaviours and dependencies, no dependency injection framework needed.

Please don't judge Haskell using Scala and scalaz.

Re: Diminishing returns of static typing

#364

Post by jcelerier »

stagger87 wrote: post #362
geofft wrote: post #118

Earlier quoted context omitted.

What are your favorite tools for doing this in C/C++ (which are extremely statically typed, if not very strongly typed)? I think the best thing I've found for this personally is coccigrep, which works but I've only used it a couple of times. I'd like something I'd reach for about as often as I reach for grep. (Also I think these days you'd want it to be based on clang or something.) One thing that does seem to be tru…

QtCreator

Here are the refactorings available : http://doc.qt.io/qtcreator/creator-editor-refactoring.html

Also they are backed by Clang and muuuuuuuuuuuch faster than in Visual Studio + whatever paid extension

A very nice feature it has and that I didn't see elsewhere is the optional case-sensitive renaming. eg renaming Foo to Bar will also change foo to bar and FoO to BaR.

Re: Diminishing returns of static typing

#365

Post by xfer »

mpartel wrote: post #158
willtim wrote: post #115

Earlier quoted context omitted.

In retrospect, HKTs are arguably Haskells greatest innovation, enabling extremely general abstractions and huge amounts of code reuse.

In my subjective opinion, Haskell has taken abstraction way past the point of diminishing returns, at least for the problems I tend to work on. A large portion of advanced Haskell type system features seem to be about emulating things you could do with side-effects. I guess I prefer Rust's approach to managing side-effects, or even just Scala's implied convention of: use 'var' very sparingly, and mostly locally. Yes,…

Rust doesn't have anyway to manage side-effects in types ..

Re: Diminishing returns of static typing

#366

Post by FiveDegrees »

icebraining wrote: post #188
mpartel wrote: post #54

Having programmed in languages ranging from Ruby to Coq, for web apps and games, I feel the sweet spot is somewhere in the neighborhood of Java/C#, i.e. include generics but maybe leave out stuff like higher kinds and super-advanced type inference (and null!). The main use case of generics, making collections and datastructures convenient and readable, is more than enough to justify the feature in my view, since virt…

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.

Re: Diminishing returns of static typing

#367

Post by girvo »

emodendroket wrote: post #235
cle wrote: post #95

Earlier quoted context omitted.

Agree. My point is that, if I personally dislike C# (I don't), and I'm on a team of C# experts and C# is the best choice for shipping the product given those experts and all the other use cases, then C# is the best tool for the job and I'll peruse C# documentation. I try my best to focus objectively on the product, not my ego or subjective preferences...and I often fail :(.

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.

Re: Diminishing returns of static typing

#368

Post by naedish »

Guthur wrote: post #355
lomnakkus wrote: post #320

Earlier quoted context omitted.

It seems to me that you've just invented a static type checker. (Combined with a run-time type checker.) Am I mistaken? I mean, we can argue the semantics of what, exactly "static type checker" means, but...

Not sure it's really an invention, it's been around for awhile. Check any decent common lisp implementation.

I'm pretty sure he doesn't mean invented in a literal sense. The phrasing implies a meaning of reinvented.

Re: Diminishing returns of static typing

#369

Post by andybak »

KMag wrote: post #206
macspoofing wrote: post #60

Earlier quoted context omitted.

I'm so happy to see the pendulum swing the other way, because when JavaScript was becoming popular, and Ruby and Python had a popularity renaissance (around mid to late 2000s), I had a lot of online arguments about the value of static typing. People were complaining about static typing for the dumbest reasons (it's too 'wordy'). It started as a backlash against old-school enterprise Java development (which was fair,…

I've worked with, statically typed languages, dynamically typed languages, and my day job involves a dynamically typed language with optional annotations (dynamically enforced) and static analysis tools. In my experience, the cost of static typing feels roughly constant per line of code, while the benefits of static typing feel roughly O(N log N) in lines of code or O(N) in number of cross-type interactions. These ar…

There are no large codebases - just insufficiently modular ones. :-)

Re: Diminishing returns of static typing

#370

Post by 32days8kd »

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…

I had a related reaction, which is that the problems you're mentioning can become more complex when using libraries outside the standard library with static languages.

E.g., my experience is that poor library design can sometimes be exacerbated in statically typed languages if the type logic is poor and doesn't match the problem domain. Dynamic languages sometimes inadvertently "correct" for this by smoothing over these sorts of issues.

I prefer static languages (or at least optionally typed ones) but there can be big downsides of the sort you're mentioning, that are exacerbated by third-party libraries.

Post reply on HN