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

601–610 of 632 posts

Re: Diminishing returns of static typing

#601

Post by yawaramin »

hellofunk wrote: post #506
yawaramin wrote: post #495

Earlier quoted context omitted.

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, bu…

> ... static typing does not catch value-related bugs, but Clojure.spec can.

Can you provide an example?

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

Scala:

    def foo(param1: Int, param2: Int): Int = {
      require(param2 > param1, "Param2 must > param1")

      param2 - param1 ensuring { result =>
        result >= 5 && result

Re: Diminishing returns of static typing

#602

Post by [deleted] »

alkonaut wrote: post #265

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…

[deleted]

Re: Diminishing returns of static typing

#603

Post by zmmmmm »

deepGem wrote: post #488
zmmmmm wrote: post #419

Earlier quoted context omitted.

> For any code base that isn't a throwaway like a one-off script or similar, say 10 or 20 years maintenance I think one of our problems is that people have downgraded the importance of this. Much code nowadays (rightly or wrongly) is considered "disposable" - people think that the likelihood of any given piece of code they are writing as surviving more than a few years is negligible. It is a natural assumption when y…

And half the reason we keep throwing code away is because it was created without consciousness of maintainability. Well, this has nothing to do with static vs dynamic typing. You can write unmaintainable code in static languages very easily. In startups, developers often overlook maintainability, I completely agree but that's because everyone knows that the code you are writing today might not be needed 2 years down…

It's not totally divorced from the static vs dynamic argument. One of the main arguments people deploy for dynamic typing is that most type declarations are boilerplate and take time to code but don't add any value. But the reality is that they do add value because they enhance the readability and maintainability of the code (and this is one reason I'm not even a great fan of type inference in many situations). So it comes back to the value of maintainability vs getting your first iteration of the code to work.

Re: Diminishing returns of static typing

#604

Post by ztjio »

narimiran wrote: post #550
ztjio wrote: post #526

Earlier quoted context omitted.

My first big love in languages was Turbo Pascal, because, it was the first one I learned. So many people do this, fall in love with the first language they understand. My second big love in languages was Python. It's also the language in which I wrote my first major software product. It was this product that taught me to hate Python. Not because it was hard to create, or because quality was low. In fact, I was VERY F…

> Sadly now I'm moving into the data science/data engineering field and everything is Python and I don't know. I don't want to go back to this nightmare. Now there are (optional) type annotations and mypy [0]. I've been using them in my latest projects and I found them useful/helpful. [0] http://mypy-lang.org/

I started out with that in mind when I was initially working on some PySpark code. It fell completely apart the moment I had to include boto3 libraries. In fact, I'd hold boto3 as the pinnacle example of searingly awful garbage that languages like Python promote. Completely impossible to do even the slightest static analysis of a library that's 100% dynamically generated at runtime.

The worst part is that versions of the API for other languages are fine. It's just the Python one they decided to go all "clever junior developer" on.

Re: Diminishing returns of static typing

#605

Post by gnaritas »

igouy wrote: post #593
gnaritas wrote: post #571

Earlier quoted context omitted.

Don't be a douche, obviously I don't think it's the same hence my comment. And I'm willing to bet, same as you, my source was Google to verify my memory of something I read long ago.

If I'd read it as obvious I wouldn't have made that comment: your name-calling is unhelpful. We still don't know if you simply confabulated your other claim.

I didn't name call, saying don't be something isn't remotely the same as saying you are something. If someone tells you don't be a jerk, they're not calling you a jerk, they're warning you you're nearing that point. We're done, good will has exited the building, there's no point in continuing.

Re: Diminishing returns of static typing

#606

Post by naasking »

zbobet2012 wrote: post #597
naasking wrote: post #480

Earlier quoted context omitted.

> This is no different from writing tests in a dynamic language. Types and tests are not equivalent. This is a prevalent myth among dynamic typing enthusiasts. There is no unit test that can ensure, eg. race and deadlock freedom, but there are type systems that can do so. There are many such properties, and tests can't help you there. Types verify stronger properties than tests will ever be able to, full stop. You do…

To add some color here on the difference between a type proof and a test: consider that you can never test all possible strings for reverse. However, a type proof can show that reverse, reverses all possible strings. It is possible to test that a function on 16 bit integers returns the correct value for all inputs. Doing so would be a proof by exhaustion. Type based proofs let us prove things using other methods than…

Indeed, or to summarize as a soundbite: tests can only prove existential properties but types can prove universal properties.

Re: Diminishing returns of static typing

#607

Post by naasking »

tom_mellior wrote: post #592
naasking wrote: post #561

Earlier quoted context omitted.

> It's just a very very weak one, so weak as to be almost entirely useless. Weak and strong aren't meaningful terms. A machine ISA might have an inexpressive type system and/or an unsound type system (because it conflates addresses and integers). > 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. No, t…

>> It's for architectural reasons. > No, it's for architectural reasons. You win, I guess?

I'm not sure who you're quoting, but I never even used the word "architecture". I don't even know what that's supposed to mean.

Re: Diminishing returns of static typing

#608

Post by s17n »

eastWestMath wrote: post #590
s17n wrote: post #585

Earlier quoted context omitted.

Defining "correctness" in terms of types is the CS equivalent of defining "risk" in terms of volatility - it replaces a real and fundamentally unsolvable problem with a problem that, while it has the advantage of being tractable, isn't actually all that important to solve. Great for publishing papers, dangerous when people start confusing the fake problem and the real problem.

And you’re just doubling down on sophistry. Why should anyone take you seriously in this conversation?

Saying "you're doubling down on sophistry" instead of just "you're wrong" doesn't actually make you more convincing.

Re: Diminishing returns of static typing

#609

Post by kazinator »

lomnakkus wrote: post #595
kazinator wrote: post #447

Earlier quoted context omitted.

Static checking doesn't make a "static language". A "static language" occurs when we have a model of program execution that involves erasing all of the type info before run-time. Or most of it. (Some static languages support OOP, and so stuff some minimal type info into objects for dispatch.) Note how above, my expression executes anyway; the checks produce only warnings. The warning for the lack of a binding for the…

This really sounds like "semantics" to me (not PL semantics! :). For example, these days it's quite possible to ask GHC to defer type errors to runtime. Does that mean that the GHC dialect of Haskell is dynamically typed? This is basically a command line switch away, btw. Retention of type information does not "dynamic typing" make. As a trivial example, consider C++ RTTI. You really have just reinvented static (type…

C++ RTTI is only for class objects, and only useful when they are manipulated by pointer or reference. I believe I covered that sort of thing with my statement, "Some static languages support OOP, and so stuff some minimal type info into objects for dispatch.". It's a gadget which provides an alternative to the structure of doing everything via virtual functions on a base class reference.

Re: Diminishing returns of static typing

#610

Post by huhlig »

cpitman wrote: post #477
irrational wrote: post #468

Earlier quoted context omitted.

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…

I also consult for Fortune 500 companies on a regular basis, and most of them still have core business processes running on mainframe code bases well older than 10 years. No one is doing major greenfield development on mainframes, but they still exist all over the place.

I think IBM and their Z division would disagree. IBM Z Users: The 10 top insurers, 44 of the top 50 banks, 18 of the top 25 retailers, 90% of the largest airlines
Post reply on HN